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Updated IANA Considerations for Diameter Command Code Allocations 
Abstract 


The Diameter base specification, described in RFC 3588, provides a 
number of ways to extend Diameter, with new Diameter commands (i.e., 
messages used by Diameter applications) and applications as the most 
extensive enhancements. RFC 3588 illustrates the conditions that 
lead to the need to define a new Diameter application or a new 
command code. Depending on the scope of the Diameter extension, IETF 
actions are necessary. Although defining new Diameter applications 
does not require IETF consensus, defining new Diameter commands 
requires IETF consensus per RFC 3588. This has led to questionable 
design decisions by other Standards Development Organizations, which 


chose to define new applications on existing commands -- rather than 
asking for assignment of new command codes -- for the pure purpose of 
avoiding bringing their specifications to the IETF. In some cases, 


interoperability problems were an effect of the poor design caused by 
overloading existing commands. 


This document aligns the extensibility rules of the Diameter 
application with the Diameter commands, offering ways to delegate 
work on Diameter to other SDOs to extend Diameter in a way that does 
not lead to poor design choices. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5719. 
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1. Introduction 


The Diameter Base specification, described in [RFC3588], provides a 
number of ways to extend Diameter, with new Diameter commands (i.e., 
messages used by Diameter applications) and applications as the most 
extensive enhancements. [RFC3588] illustrates the conditions that 
require the definition of a new Diameter application or a new 
command. Depending on the scope of the Diameter extension, IETF 
actions are necessary. Although defining new Diameter applications 
does not require IETF consensus, defining new Diameter commands 
requires IETF consensus per RFC 3588. This has led to questionable 
design decisions by other Standards Development Organizations (SDOs), 


which chose to define new applications on existing commands -- rather 
than asking for assignment of new command codes -- for the pure 
purpose of avoiding bringing their specifications to the IETF. In 


some cases, interoperability problems were an effect of poor the 
design caused by overloading existing commands. 


This document aligns the extensibility rules for Diameter command 
codes with those defined for Diameter application identifiers and 
offers a consistent way to delegate work on Diameter to other SDOs to 
extend Diameter in a way that does not lead to poor design choices. 
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This is achieved by splitting the command code space into ranges and 
providing different allocation policies to them: the first range is 
reserved for RADIUS backward compatibility, allocation of a command 
code in the second number range requires IETF review, the third range 
is utilized by vendor-specific command codes, and finally the last 
range is for experimental commands. Section 4 provides more details 
about the command code number ranges, and the different allocation 
policies are described in [RFC5226]. 


A revision of RFC 3588 is currently in development in the IETF DIME 
WG [RFC3588bis]; when approved, it will obsolete RFC 3588 as well as 
this document. A goal of this document is to provide in advance the 
change in the command codes allocation policy, so that 
interoperability problems like the ones described above are avoided 
as soon as possible. 


2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Security Considerations 


This document modifies the IANA allocation of Diameter command codes 
in relationship to RFC 3588. This process change itself does not 
raise security concerns, but the command code space is split into a 
standard command code space and a vendor-specific command code space, 
the latter being allocated on a First Come, First Served basis by 
IANA at the request of vendors or other standards organizations. 
Whenever work gets delegated to organizations outside the IETF, there 
is always the chance that security reviews will be conducted in 
different manner and that the criteria and style of those reviews 
will be different than the reviews performed in the IETF. The 
members of the DIME working group are aware of the risks involved in 
using different security and quality review processes and of the 
desire to offload work (e.g., to reduce the workload in the IETF) to 
other organizations. Other organizations are therefore made 
responsible for the quality of the specifications they produce. 


4. IANA Considerations 
This section describes changes to the IANA Considerations sections 
outlined in RFC 3588 regarding the allocation of command codes by 


IANA. 


The command code namespace is used to identify Diameter commands. 
The values 0 - 255 (0x00 - Oxff) are reserved for RADIUS backward 
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6. 


6. 


compatibility and are defined as "RADIUS Packet Type Codes" in 
[RADTYPE]. Values 256 - 8,388,607 (0x100 - Ox7fffff) are for 
permanent, standard commands allocated by IETF Review [RFC5226]. 
[RFC3588] defines the command codes 257, 258, 271, 274, 275, 280, and 
282; see Section 3.1 in [RFC3588] for the assignment of the namespace 
in that specification. 


The values 8,388,608 - 16,777,213 (0x800000 - Oxfffffd) are reserved 
for vendor-specific command codes, to be allocated on a First Come, 
First Served basis by IANA [RFC5226]. The request to IANA for a 
vendor-specific command code SHOULD include a reference to a publicly 
available specification that documents the command in sufficient 
detail to aid in interoperability between independent 
implementations. If the specification cannot be made publicly 
available, the request for a vendor-specific command code MUST 
include the contact information of persons and/or entities 
responsible for authoring and maintaining the command. 


The values 16,777,214 and 16,777,215 (hexadecimal values Oxfffffe - 
Oxffffff) are reserved for experimental commands. As these codes are 
only for experimental and testing purposes, no guarantee is made for 
interoperability between Diameter peers using experimental commands, 
as outlined in [RFC3692]. 
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